Skip to content

Conversation

AlexeySachkov
Copy link
Contributor

The specification can be found in KhronosGroup/SYCL-Docs#814

The implementation is a non-functional change for the existing codebase, but definitions of macro documented by the SYCL 2020 specifications were moved around a little bit to provide them all through the new sycl/khr/version.hpp.

New headers are always present and their content is always available. However, we do not define SYCL_KHR_INCLUDES macro yet because the extension is still on review. That indicates that it is not formally supported by the implementation.

@AlexeySachkov AlexeySachkov force-pushed the private/asachkov/sycl-khr-includes branch from 9011b04 to 9d73285 Compare October 13, 2025 16:31
@AlexeySachkov AlexeySachkov marked this pull request as ready for review October 15, 2025 15:47
@AlexeySachkov AlexeySachkov requested a review from a team as a code owner October 15, 2025 15:47
// a version.
// However, we may need to have some fallback here if someone includes SYCL
// headers into their host applications and use 3rd-party compilers.
// #error "SYCL_LANGUAGE_VERSION is not defined, please report this as a bug"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nothing happens here. do we need this dead code and comment then? I suggest to add it when it will be needed and will do something depending on condition.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Those lines worth discussion, I think.

My original intent was to add a guardrail about us refactoring the compiler, but forgetting to define it in headers (or rather defining it in a header other than version.hpp).

However, that attempt failed because apparently we ourselves have an application (sycl-ls) that is built with a 3rd-party compiler (i.e. host gcc or whatever), but uses SYCL headers.

Do we want our headers to be usable with 3rd-party compilers? By that I mean directly using g++ -I/path/to/sycl/includes -include sycl.hpp instead of clang++ --fsycl-host-compiler=g++. We actually have a feature request about this: #5932

If we do want such support, then we should probably define SYCL_LANGUAGE_VERSION macro here. If not, then #error is the right way to go and we need to fix how we build sycl-ls

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we do have a warning for this case https://github.com/intel/llvm/blob/sycl/sycl/include/sycl/sycl.hpp#L27
that shows absence of guarantee and doesn't block usage by 3rd party compiler if someone want to try. Why can't we stick to the same approach?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for reminding me about that diagnostic. If we explicitly claim it to be erroneous, then I would remove the #ifdef completely, providing no guarantee of SYCL_LANGUAGE_VERSION being defined in such mode.

Copy link
Contributor

@KseniyaTikhomirova KseniyaTikhomirova left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants